home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 170_01 / zapload.doc < prev    next >
Text File  |  1980-01-01  |  9KB  |  260 lines
  1. .he ZAPLOAD- Binary to Intel Hex (c) T. Jennings 1980, 1981, 1982 Page #
  2.  
  3.  
  4.      ZAPLOAD- MSDOS version
  5.  
  6.     ZAPLOAD  can  be  used  to convert any  file  (binary  is 
  7. assumed)  to  INTEL  hex  format,   and  send  to  one  or   more 
  8. destinations:  a  disk file,  the punch device,  or the  printer. 
  9. There  are  many options to select various things;  ones or  twos 
  10. complement checksums,  where to send the hex, specifying the load 
  11. and start addresses, etc. All of the available options are listed 
  12. below, followed by a more detailed description of each. 
  13.  
  14.     The  very  last section deals with connecting  a  Sunrise 
  15. Electronics ZAP-80 EPROM burner to a computer via ZAPLOAD,  since 
  16. that was it's original intent.
  17.  
  18.     ZAPLOAD  gives  a  quick list  and  description  of  it's 
  19. commands when operated improperly. To get this list, type ZAPLOAD 
  20. without  any  command line options.  You will also get  the  list 
  21. whenever you make any command errors.
  22.  
  23. .pa
  24.  
  25.  
  26.     Zapload  is executed from an MSDOS system,  and  converts 
  27. MSDOS files from the disk,  to INTEL hex format.  All options are 
  28. specified  on the command line when ZAPLOAD is run.  ZAPLOAD  has 
  29. the following syntax:
  30.  
  31.     ZAPLOAD <file to convert> <any legal options ...>
  32.  
  33.  
  34.     After  ZAPLOAD has sent the entire file,  it will display 
  35. on  the console a 16 bit two's complement checksum of every  data 
  36. byte sent.  This checksum is of the data bytes only.  This can be 
  37. used  in  conjunction  with the  destination  device  to  provide 
  38. another check of data integrity.
  39.  
  40.     An  INTEL hex file consists of one or more data  records, 
  41. followed  by  an  end  of file record.  These  records  have  the 
  42. following format:
  43.  
  44.     DATA RECORDS: : bb llll tt dd dd dd .... cc
  45.  
  46.     : says this is the start of a record,
  47.     bb is the number of data bytes to follow,
  48.     llll is the address to load the data byte at,
  49.     tt is the record type, 00 for data,
  50.     dd dd ... are the data bytes,
  51.     cc is the checksum of bb llll tt and all dd data
  52.     bytes.
  53.  
  54.     END OF FILE RECORDS: : bb ssss tt cc
  55.  
  56.     : is the same as a data record,
  57.     bb is zero, (no data),
  58.     ssss is the program start address,
  59.     tt is 01 to indicate end of file,
  60.     cc is the checksum of bb ssss and tt. 
  61.  
  62.     There are no data bytes.
  63.  
  64.     After  the cc bytes have been sent,  a CR LF sequence  is 
  65. sent  for readability.  Programs that read INTEL hex  ignore  any 
  66. characters before the :,  and after the cc checksum.  Or at least 
  67. are supposed to.
  68.  
  69.     If  you specify no options at all,  ZAPLOAD processes the 
  70. file but does not send the output anywhere. The following are the 
  71. defaults for Intel Hex generation:
  72.  
  73.     - 32 byte data records (20 hex),
  74.     - 2's complement checksums,
  75.     - Initial load address of 0,
  76.     - Start address of 0.
  77. .pa
  78.  
  79.  
  80.     ZAPLOAD OPTIONS
  81.  
  82.     There  are  many options;  these fall  roughly  into  two 
  83. categories;  those  that  control  the record  format,  for  non-
  84. standard devices (damn them) and those that control where to send 
  85. it as it is generated.
  86.  
  87.     Options are specified on the command line,  following the 
  88. filename.  Each option is a single letter,  and may appear in any 
  89. order. Some options take an additional argument; like setting the 
  90. load  address.  In  these cases the argument follows  the  option 
  91. letter, seperated by one or more spaces, like so:
  92.  
  93.     ZAPLOAD file l 8000
  94.  
  95.     Option  letters may be optionally preceded by  a  -,  for 
  96. UNIX freaks, like so:
  97.  
  98.     ZAPLOAD file -l 8000
  99.  
  100.     RECORD FORMAT OPTIONS
  101.  
  102.     b <hex number>
  103.     Set  the number of bytes sent per record from the default 
  104. 20  hex  to <hex number>.  <hex number> must be less  than  1024. 
  105. Please do not use 0. (BUG: ZAPLOAD will not catch a byte count of 
  106. zero.  It  might  try to produce 65535  byte  records,  and  bomb 
  107. everything.)
  108.  
  109.     z
  110.     Generate  ones  complement  checksums instead  of  two's. 
  111. Obscure option for use with non-standard devices.
  112.  
  113.     l <hex number>
  114.     Set  the load address to <hex number>.  The default is  0 
  115. hex if this option is not used.  The load address for each record 
  116. sent will increment by the byte count.
  117.  
  118.     r <hex number>
  119.     Change the default run address of 0 to <hex number>. This 
  120. is used only in the end of file record,  to indicate the starting 
  121. address of the file just sent.  Things like EPROM burners do  not 
  122. use this; some computers with download facilities might.
  123. .pa
  124.  
  125.  
  126.     FILE DESTINATION CONTROLS
  127.  
  128.     The following options control where the file is sent, and 
  129. how it is sent. If none of these are specified, it is merely sent 
  130. to  the  console.  Each  record is always typed on  the  console, 
  131. character by character,  as it is sent,  unless the 'X' option is 
  132. given.  Running ZAPLOAD with only the 'X' option would cause  the 
  133. file  to be sent nowhere at all.  (Why?) A control-Z  terminating 
  134. character  is  sent to the destination device after the  file  is 
  135. transferred.
  136.  
  137.     a
  138.     Send to the aux device.  This could also be done via  the 
  139. 'f' option: f AUX. See below.
  140.  
  141.  
  142.     f <file name>
  143.     Create a file <file name>, and send each byte there. This 
  144. can be used to generate INTEL hex disk to disk, without using any 
  145. external devices. 
  146.  
  147.     w <decimal number>
  148.  
  149.     Software  delay by <decimal number> after each  character 
  150. is sent.  This can be used for those poorly designed devices that 
  151. require  but  do not use character by  character  handshake.  The 
  152. default here is 0, obviously, and 10 is about 50 milliseconds for 
  153. a  4MHz  Z80.  This  was necessary for the ZAP-80,  as is  has  a 
  154. software UART, and takes too long to process a byte to keep up. 
  155.  
  156.     Pretty useless with disk files.
  157.  
  158.     e <decimal number>
  159.  
  160.     Software  delay after the CR LF sequence at the end of  a 
  161. record.  Some loaders require more time at the end of the record, 
  162. in order to generate and check the checksum. The delay w <decimal 
  163. number> is still done after sending the last cc byte,  but not on 
  164. the CR LF sequence.
  165.  
  166. .pa
  167.  
  168.     General Controls
  169.  
  170.     s <dddd>
  171.  
  172.     Skip  <dddd> decimal bytes at the beginning of  the  file 
  173. before processing.  This is useful when generating HEX files from 
  174. CP/M .CMD files or the like that have a header at the beginning.
  175.  
  176.     o
  177.     e
  178.  
  179.     Process  only  even or odd numbered bytes.  This is  very 
  180. useful when generating EPROM code for 16 bit processors like  the 
  181. 8086,  that  have  even bytes in one PROM,  and the odd  ones  in 
  182. another. By using the form:
  183.  
  184.     zapload file.cmd s 128 e f low.hex
  185.     and
  186.     zapload file.cmd s 128 o f hi.hex
  187.  
  188.     You  can  make the two EPROM files necessary for an  8086 
  189. bootstrap ROM, or whatever.
  190.  
  191.     x
  192.  
  193.     List output on the console. All hex records generated are 
  194. typed.
  195.  
  196. .pa
  197.  
  198.     TYPICAL USAGE
  199.  
  200.     Here  are  some examples for loading INTEL  hex  to  some 
  201. common devices:
  202.  
  203.     zapload test.com x
  204.     This  loads  test.com to the console,  and sends 32  byte 
  205. records, load address of 0, start address of zero.
  206.  
  207.     zapload test.com e 10 w 10
  208.     This  loads  a ZAP80 tied to the  punch  port,  with  the 
  209. necessary software delays to accomodate the ZAP80. 
  210.  
  211.     zapload test.com f test.hex
  212.     Convert  file  test.com  to  hex,  and make  a  hex  file 
  213. test.hex. This "undoes" Digital Research's LOAD utility. 
  214.  
  215.     zapload test.com l 100 r 100 p f test.hex x
  216.     Convert test.com to Intel hex,  send it to the CP/M  PUN: 
  217. device,  to the disk file TEST.HEX,  and listing it on 
  218. the console. The load address starts at 100h, and the run address 
  219. is 100h.
  220. .pa
  221.  
  222.     Connecting the ZAP-80 to FIDO or any other computer
  223.  
  224.     You  will  not find this data in any Sunrise  Electronics 
  225. documentation.  The ZAP80 is filled with bugs,  and the manual is 
  226. terrible.
  227.  
  228.     - The ZAP80 requires 300 baud,  1 1/2 stop bits.  Idiots. 
  229. Use two stop bits.
  230.  
  231.     - The ZAP 80 cannot be run faster than 300 baud,  and can 
  232. not handle even this without software delays.
  233.  
  234.     - Though  they  claim  that  it  uses  the  RTS  line  or 
  235. whatever, it really does not. 
  236.  
  237.     - Even  though each record may be loading  properly,  the 
  238. display  will  always say there is a load error after  the  first 
  239. record.  Ignore  it,  and once the entire file is  sent,  do  the 
  240. following:
  241.  
  242.     Reset  the ZAP80,  and checksum the entire data ares